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1  Introduction 


Our  main  focus  is  to  obtain  an  understanding  of  how  security  could  be  effectively  integrated  into  real¬ 
time  systems.  Robust  systems  must  be  able  to  both  prevent  expected  attack  vectors  from  succeeding,  as 
well  as  comprehensively  monitor  themselves  and  detect  intrusion  events.  Currently,  there  does  not  exist  a 
comprehensive  theoretical  framework  for  the  integration  of  security  in  embedded  real-time  systems. 

Traditionally,  real-time  systems  are  modeled  as  a  set  of  a  periodic  tasks  with  timing  constraints  that  are 
then  scheduled  on  a  collection  of  resources  the  processor,  memory,  bus,  etc.).  A  key  insight  that  we 
believe  will  be  useful  is  in  identifying  this  resource  management  nature  of  RTS  and  the  need  for  security 
policies  to  adhere  to  the  strict  guidelines  imposed  as  a  result.  Hence,  any  security  related  mechanisms  must 
work  within  the  imposed  restrictions  of  timeliness,  determinism,  etc .  On  the  other  hand,  these  properties 
of  RTS  actually  make  it  easier  to  model  such  systems  and  perform  a  rigorous  analysis  of  any  solutions  that 
will  be  developed* 

1*1  Specific  Problem  and  Tangible  Results 

The  goals  of  this  effort  are  the  development  of  a  new,  genera  li  zed,  framework  for  the  integration  of  security  and 
real-time  systems  that  will  involve  a  combination  of  research  along  the  following  axes: 

L  Understanding  and  classification  of  current  and  emerging  threat  landscapes  for  such  systems  -  what  types 
of  vulnerabilities  exist,  what  attacks  are  possible,  what  security  properties  are  essential. 

2.  Security  policies  and  system  models  that  bring  the  seemingly  diverse  areas  of  real-time  systems  and 
security  together  to  develop  a  framework  for  resource  management  algorithms  in  real-time  systems* 

3.  Development  of  security  mechanisms  that  leverage  real-time  resource  managers  that  will  (a)  prevent  at¬ 
tacks  from  being  successful  and/or  (b)  detect  any  intrusions /attacks  once  they  occur  and  (c)  keep  the 
overall  system  safe  in  the  event  of  an  attack* 

4.  Analysis  and  evaluation  of  the  effectiveness  of  the  proposed  mechanisms,  both  in  terms  of  their  capabil¬ 
ity  to  meet  real-time  requirements,  as  well  as  their  ability  to  improve  the  security  of  the  system*  We  will 
follow  an  experimental  methodology  based  on  the  development  of  suitable  case  studies  and  demonstra¬ 
tion  platforms. 

1.2  Approach 

We  are  working  on  understanding  how  the  resource  management  nature  of  such  systems  affects  the  process 
of  integrating  security.  To  this  effect,  we  analyze  existing  systems  to  gain  and  understanding  of  (a)  what 
security  problems  can  manifest  themselves  and  (b)  how  they  can  be  fixed  in  the  context  of  the  various 
resource  managers  in  the  system*  We  will  present  some  initial  work  along  these  lines  in  Section  2* 

1.3  Research  Plan  and  Milestones 

We  proposed  a  three  year  plan  of  work  for  our  research  and  continue  to  make  progress  along  the  same 
lines.  In  the  first  year,  we  focused  on  what  we  call  a  "vertical  slice "  of  the  problem  to  show  the  feasibility 
of  the  approach.  We  modeled  a  set  of  real-time  tasks  with  security  relationships  ordered  as  as  lattice  of  se¬ 
curity  levels*  In  the  second  year,  we  significantly  expanded  the  scope  of  the  work  to  improve  the  analysis, 
developed  a  more  general  model  (what  we  called  a  "vendor-based  model")  to  describe  security  relation¬ 
ships  between  tasks,  analyzed  the  effects  of  preemption  and  resource  (cache)  partitioning  and  also  started 
to  develop  ideas  on  how  to  carry  out  an  attack  on  real-time  systems*  In  the  third  year  (and  beyond),  we 
expanded  our  work  in  both  security  integration  and  attack  mechanisms,  and  worked  on  demonstrations 
and  evaluations  in  hardware. 

Year  I:  In  the  first  year,  we  looked  at  a  specific  range  of  issues  in  each  of  the  domains:  viz.,  security  vulner¬ 
abilities,  real-time  architectures,  scheduling  and  resource  management  algorithms  and  mitigation  mech¬ 
anisms,  all  in  the  scope  of  a  particular  application  domain.  For  our  application  domain,  we  focused  on 
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unmanned  aerial  vehicles  (UAVs)1  Sections  2  and  2.3  provide  details  on  our  work  on  these  topics. 

In  the  first  year,  we  focused  on  security  attacks  that  threaten  the  confidentiality  and  integrity  of  real-time 
systems.  Our  research  was  aimed  at  mitigating  such  problem  by  creative  scheduling  (and  broader  resource 
management)  algorithms.  While  our  initial  work  is  focused  on  single-core  systems,  we  plan  to  expand  this 
to  multicore  systems  -  they  bring  up  interesting  problems  of  their  own  due  to  the  co- location  of  real-time 
tasks.  We  also  plan  to  generalize  our  application  model  (from  Sections  2 .3  and  2.3.2)  that  can  then  be  used 
by  us  (and  the  real-time  community)  for  research  on  real-time  security. 

Year  II:  We  expanded  the  work  from  the  first  year  by  generalizing  the  model  to  describe  the  security  re¬ 
lationships  between  real-time  tasks.  We  named  it  the  vendor-based  mode.!.  We  then  developed  a  close-to- 
optimal  algorithm  to  determine  the  overhead  for  the  security  mechanisms  developed  in  year  1.  We  also 
analyzed  the  effects  of  preemption  in  such  scenarios.  Another  related  topic  that  we  explored  was  how 
a  partitioning  of  the  underlying  shared  resources  (e,g.f  caches)  help  reduce  the  effects  of  attacks  that  we 
explored  in  year  1  (leakage  of  information  through  the  cache). 

Finally,  we  started  working  on  demonstrating  actual  attacks  that  can  be  used  to  leak  information.  This 
process  requires  two  steps:  (a)  an  understanding  of  the  exact  schedule  of  tasks  that  are  executing  and  (h) 
using  this  information  to  launch  a  cache  timing  attack  on  a  specific  task. 

Year  III:  In  the  third  year,  we  further  expanded  our  work  in  both  security  and  attack  mechanisms  from 
the  second  year.  We  developed  a  scheme  to  integrate  security  policies  in  legacy  systems  using  opportunistic 
execution  [3].  A  metric,  by  means  of  achievable  periodic  monitoring,  was  proposed  to  measure  security  of 
the  system  in  such  work.  We  also  develop  a  schedule  randomization  protocol,  TaskShuffler  [8],  to  reduce 
periodicity  of  the  schedules  in  hard  real-time  systems  that  will  make  it  harder  for  attacker  to  extract  system 
behavior.  On  the  other  hand,  the  developed  schedule-based  attack  from  the  second  year  is  further  refined 
to  tolerate  variations  in  system  attributes,  making  the  attack  more  applicable  to  realistic  platforms  [1,2]. 

1.4  Advantages  of  the  Approach 

The  main  advantages  of  this  approach  are: 

1.  Introduction  of  security  in  RTS  at  a  holistic  level; 

2.  Makes  the  design  of  RTS  inherently  more  secure; 

3.  Will  not  require  hardware  changes,  at  least  initially; 

4.  Better  understanding  of  the  security  challenges  in  the  field  of  Real-Time  Systems, 

2  Current  State  and  Results 

Publications: 

1.  '* Real-time  Security  through  Scheduler  Consfniwfs"  published  in  Euromicro  Conference  on  Real-Time  Sys¬ 
tems  (ECRTS),  Madrid,  July  2014. 

2.  " A  Generalized  Model  from  Preventing  Information  Leakage  in  Hard  Real-Time  Systems/'  published  in  Real- 
Time  and  Embedded  Systems  and  Applications  (RTAS),  Seattle,  April  2015. 

3.  "Integrating  Security  Constraints  into  Fixed  Priority  Real-Time  Schedulers"  published  in  Real-Time  Systems 
Journal,  2016. 

4.  "TaskShuffler:  A  Schedule  Randomization  Protocol  for  Obfuscation  Against  Timing  Inference  Attacks  in  Real- 
Time  Systems "  published  in  22nd  IEEE  Real-Time  and  Embedded  Technology  and  Applications  Sympo¬ 
sium  (RTAS),  April  2016. 

1  These  ideas  can  also  be  applied  to  unmanned  underwater  vehicles  {UUVs),  In  this  work  we  focus  on  UAVs  and  will  leave  the 
demonstration  on  UUVs  for  future  work. 
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5,  " ScheduLeak :  An  Algorithm  for  Reconstructing  Task  Schedules  in  Fixed -priority  Hard  Real-time  Systems " 
presented  in  1st  Workshop  on  Security  and  Dependability  of  Critical  Embedded  Real-Time  Systems 
(CERTS),  November  2016. 

6.  " Exploring  Opportunistic  Execution  for  Integrating  Security  into  Legacy  Hard  Real-Time  Systems"  in  IEEE 
Real-Time  Systems  Symposium  (RTSS),  November  2016. 

We  now  present  detailed  information  about  what  we  have  achieved  in  the  past  three  years, 

2.1  Integrating  Security  into  Real-Time  Scheduling 

We  identified  one  security  problem  -  that  of  confidentiality  when  a  system  has  shared  resources,  e.g.f  caches, 
buses,  cfc.Our  initial  focus  is  to  identify  how  this  problem  can  be  reconciled  with  the  traditional  real-time 
scheduling  requirements  on  single  core  processors, 

2.1.1  Information  Leakage  Prevention 

It  has  been  shown  that  the  use  of  shared  resources  makes  it  possible  for  information  to  be  leaked  between 
tasks  without  the  use  of  explicit  communication  [4,6],  The  issue  of  covert  timing  channels  between  tasks 
of  different  security  levels  in  the  RM  scheduler  was  previously  considered  [7].  We,  in  contrast,  focus  on 
information  leakage  due  to  the  sharing  of  resources2  such  as  the  cache,  DRAMs,  I/O  bus,  etc. 

In  our  Year  I  work,  we  proposed  the  following:  casting  security-related  requirements  in  the  form  of  real¬ 
time  scheduling  constraints.  This  enabled  us  to  directly  reason  about  the  effects  of  integrating  security  into 
RTS  (c.g.,  effects  on  schedu  I  ability).  The  problems  related  to  information  leakage  between  real-time  tasks 
with  different  security  levels  was  an  example  of  a  security  issue  that  must  be  solved  by  these  techniques. 
We  considered  a  uniprocessor  system  following  the  Liu  and  Layla nd  task  model  [5]  that  contains  a  set  of 
sporadic  tasks  scheduled  based  on  the  Rate  Monotone  (RM)  policy.  We  are  concerned  with  the  leakage 
of  information  between  tasks  of  different  criticality  While  we  started  by  considering  a  standard  security 
model  consisting  of  a  lattice  of  security  levels,  we  found  that  in  some  cases  this  model  can  be  limited  in 
scope.  Hence,  we  developed  a  new ,  generic  model  (in  Year  II)  that  can  capture  the  exact  security  relationships 
between  every  pair  of  tasks  in  the  system;  we  discuss  this  vendor-oriented  model  in  more  details  in  Section 
2,3,2. 

More  often  than  not,  every  time  there  is  a  switch  between  tasks  belonging  to  different  security  levels 
there  is  a  possibility  of  information  leakage  through  shared  resources  such  as  the  cache.  We  believe  that 
through  the  use  of  intelligent  scheduling  mechanisms  it  is  possible  to  integrate  security  at  the  design  phase 
of  RTS  and  reduce  this  potential  for  information  leakage  via  shared  resources,  A  cost  must  be  paid  for 
each  shared  resource  in  the  system  to  prevent  this  leakage  of  information.  In  our  work,  we  discuss  various 
methods  of  integrating  such  a  penalty  (and  associated  constraints)  into  scheduling  policies  for  real-time 
systems  and  derive  analysis  bounds  for  the  same. 

We  developed  two  mechanisms  to  prevent  information  leakage  between  two  tasks.  The  first  method 
consists  in  the  use  of  a  synthetic  'flush  task'  (FT)  that  resets  the  state  of  any  resource  that  might  be  used  to 
leak  information.  For  example,  in  the  case  of  a  cache,  we  can  simply  evict  ail  cache  lines.  Note  this  incurs 
some  overhead,  both  because  dirty  cache  lines  needs  to  be  written  back  to  main  memory  upon  executing 
tlie  FT,  and  because  useful  cache  line  might  be  evicted,  forcing  the  next  executing  task  to  reload  them  in 
cache. 

The  second  mechanism  consists  in  partitioning  the  resource:  if  we  assign  to  two  tasks  disjoint  sections 
(partitions)  of  the  shared  resource,  then  there  is  no  way  for  the  tasks  to  communicate  through  said  shared 
resource.  However,  this  reduces  the  amount  of  resource  available  to  each  task,  thus  potentially  incurring  a 
timing  penalty.  For  example,  cache  can  be  partitioned  using  techniques  at  either  the  hardware  or  software 
level,  but  reducing  the  amount  of  cache  available  to  any  given  task  might  increase  the  number  of  capacity 
misses  and  thus  increase  the  execution  time  of  the  task. 

-Other  than  the  processor  core. 
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In  the  first  year  of  the  proposal,  we  focused  on  the  simpler  model  considering  an  ordered  set  of  secu¬ 
rity  levels.  Based  on  this  model,  we  proposed  a  set  of  scheduling  constraints  that  can  be  used  to  guar- 
an  tee  the  security  properties  using  a  flush  mechanism.  We  described  the  effect  of  such  constraints  over 
a  variety  of  real-time  scheduling  algorithms,  and  devised  a  schedu lability  analysis  for  the  simplest  case 
{non-preemptive  fixed-priority  scheduling). 

In  Year  II,  we  significantly  expanded  the  scope  of  the  work  by  achieving  the  following  major  contribu¬ 
tions: 

1,  We  developed  a  dose-to-optimal  algorithm  to  determine  the  number  of  flushes  required  to  guarantee 
the  security  requirements  for  a  given  task  under  analysis  under  the  vendor-oriented  model. 

2.  We  extended  such  algorithm  to  take  into  account  the  effects  of  partitioning. 

3.  Based  on  the  previous  two  points,  we  derived  a  schedu  lability  analysis  to  determine  whether  a  set  of 
real-time  tasks  can  be  scheduled  while  guaranteeing  all  security  requirements  based  on  a  combined 
flushing  and  partitioning  scheme. 

4.  Our  investigation  reveals  that  whether  a  task  is  executed  preemptively  or  not  has  a  large  impact  on 
the  overhead  of  the  devised  security  mechanisms.  Hence,  we  developed  an  algorithm  to  optimally 
determine  whether  each  task  should  be  executed  preemptively  or  not. 

5,  We  created  a  design-exploration  methodology  to  allow  the  designer  to  search  for  an  optimal  system 
configuration.  The  main  idea  behind  our  design  exploration  technique  is  that  different  tasks  are  more  or 
less  susceptible  to  the  effects  of  partitioning,  i.e,,  tasks  with  small  working  sets  can  be  assigned  to  small 
partitions,  while  tasks  with  large  working  sets  need  the  entire  resource.  This  allows  us  to  reduce  the 
overhead  of  flushing  by  assigning  less-sensitive  tasks  to  separate  partitions. 

6,  To  study  the  effectiveness  of  our  solutions,  we  are  currently  working  on  demonstrating  an  attack  on  a 
typical  unmanned  vehicle  platform  -  we  intend  to  show  how  an  attacker  can  gauge  the  exact  schedule 
of  the  system  and  then  use  it  to  launch  a  cache-based  side-channel  attack.  Section  2.2  provides  more 
information  on  this  topic. 

2.1.2  Integrating  Monitoring  and  Detection  Mechanisms  in  Legacy  RTS 

Given  the  increasing  risk  of  cyber  attacks,  it  is  essential  to  have  a  layered  defense  and  integrated  resilience 
against  such  attacks  into  the  design  of  RTS.  However,  any  security  mechanisms  have  to  co-exist  with  real¬ 
time  tasks  in  the  system  and  have  to  operate  without  impacting  the  timing  and  safety  constraints  of  the 
control  logic.  Besides,  the  embedded  nature  of  these  systems  limits  the  availability  of  computational  power 
(e*g*t  memory  or  processor)  required  for  resource-extensive  monitoring  mechanisms.  This  creates  an  appar¬ 
ent  tension  between  security  requirements  (e.g.,  having  enough  cycles  for  effective  monitoring  and  detec¬ 
tion)  and  the  timing  and  safety  requirements.  For  example,  a  critical  parameter  is  to  determine  how  often 
and  how  long  should  a  monitoring  and  intrusion  detection  task  execution  to  be  effective  but  not  interfere 
with  real-time  control  or  other  safety-critical  tasks.  While  this  tension  could  potentially  be  addressed  for 
newer  systems  at  design  time,  this  is  especially  challenging  for  retrofitting  legacy  systems  where  the  control 
tasks  are  already  in  place  and  perhaps  cannot  be  modified .  Any  hardware  and/or  software-level  modifica¬ 
tions  to  those  legacy  system  parameters  is  costly  since  it  will  go  through  several  verification  and  validation 
steps  and  may  increase  system  downtime. 

Given  the  tension  between  security  and  timing  requirements,  while  integrating  security  mechanisms 
into  a  practical  system,  finding  the  frequency  of  execution  of  the  monitoring  tasks  is  an  important  design 
parameter  that  trades  security  requirements  with  timing  constraints.  If  the  interval  between  consecutive 
monitoring  events  is  too  large,  the  adversary  may  harm  the  system  (and  remain  undetected)  between  two 
invocations  of  the  security  task.  In  contrast,  if  the  security  tasks  are  executed  very  frequently  then  it  may 
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impact  the  schedulability  of  the  real-time  tasks.  Herein  lies  an  important  trade-off  between  monitoring 
frcq  u  et wy  a  1 1  d  schcd  it!  a  hi  I  i  ty . 

To  integrate  security  tasks  into  legacy  RTS,  in  preliminary  work  [3]  we  address  the  problem  of  deter¬ 
mining  the  frequency  of  execution  (e.g.,  periods  or  inter-monitoring  interval)  of  the  security  tasks.  Our 
approach  to  integrate  security  without  perturbing  real-time  scheduling  order  is  to  execute  security  tasks  at 
a  lower  priority  tasks  than  real-time  tasks.  We  refer  this  scheme  as  opportunistic  execution  since  the  security 
tasks  are  only  allowed  to  execute  opportunistically  only  during  slack  limes  when  no  other  real-time  tasks 
are  running. 

We  propose  to  measure  the  security  of  the  system  by  means  of  the  achievable  periodic  monitoring.  Let  T, 
be  the  period  of  the  security  task  that  needs  to  be  determined.  Since  our  goal  is  to  minimize  the  perturba¬ 
tion  between  the  achievable  (i.e.,  unknown)  period  T*  and  the  desired  period  Tfe3,  we  define  the  following 
metric:  that  denotes  the  tightness  of  the  frequency  of  periodic  monitoring  for  the  security  task  77. 

Thus  7)  =  5Z  denotes  the  cumulative  tightness  of  the  achievable  periodic  monitoring  for  a  set  of  secu- 

t,€Vs 

rity  tasks  Vs  where  w*  is  the  designer  provided  weighing  factor  that  may  reflect  criticality  or  severity  of  the 
security  tasks.  This  monitoring  frequency  metric  provides  one  way  to  trade-off  security  with  schedulability 
-  if  the  interval  between  consecutive  monitoring  events  is  too  large,  an  adversary  may  remain  undetected 
and  harm  the  system  between  two  invocations  of  the  security  task,  on  the  other  hand,  a  very  frequent  ex¬ 
ecution  of  security  tasks  may  negatively  impact  the  schedulability  of  the  real-time  tasks.  Hence,  to  find 
the  desired  77  of  the  target  system  we  formulate  a  constraint  optimization  problem  and  also  developed  a 
polynomial-time  solution  that  allows  us  to  execute  security  routines  with  a  frequency  closer  to  the  desired 
values  while  respecting  the  temporal  constraints  of  the  other  real-time  tasks. 

2,1 .3  Sch ed ule  Ran d  omiza  tion  Protocol 

One  way  to  protect  a  system  from  certain  attacks  (c.g.,  the  schedule-based  side-channel  attack)  is  to  random¬ 
ize  the  task  schedule  to  reduce  the  deterministic  nature  of  periodic  real-time  applications.  By  randomizing 
the  task  schedules  we  can  enforce  non-determinism  since  every  hyper-period  will  show  different  order 
(and  timing)  of  execution  for  the  tasks.  Unlike  traditional  systems,  randomizing  task  schedules  in  RTS  is 
not  straightforward  since  it  leads  to  priority  inversions  that,  in  turn,  may  cause  missed  deadlines  -  hence, 
putting  the  safety  of  the  system  at  risk. 

Hence,  we  proposed  TaskShuffler  [8],  a  randomization  protocol  for  fixed-priority  scheduling  algorithm,  to 
achieve  such  randomness  in  task  schedule.  For  instance,  by  picking  a  random  task  instead  of  the  one  with 
the  highest-priority  at  each  scheduling  point,  subject  to  the  deadline  constraints.  The  degree  of  randomness 
is  flexible  in  TaskShuffler ,  Based  on  the  system's  needs,  TaskShuffler  implements  the  following  randomization 
schemes: 

•  Randomization  (Task  Only):  This  is  the  most  basic  form  of  randomization  in  contrast  to  other  schemes 
introduced  below.  We  randomly  pick  a  task  to  execute  whenever  a  task  arrives  or  finishes  its  job,  /. t\,  at 
the  scheduling  points.  The  effectiveness  against  the  schedule-based  side-channel  attack  is  limited  since 
the  busy  intervals  in  this  scheme  remains  the  same. 

•  Randomization  with  Idle  Time  Scheduling:  In  addition  to  the  randomness  provided  in  the  basic  scheme, 
we  include  the  idle  task  ( e.g.f  the  dummy  task  executed  by  an  RTOS  when  other  real-time  tasks  are  not 
running)  at  each  scheduling  point.  It  eliminates  the  periodicity  of  busy  intervals  (from  hyper-period's 
point  of  view).  This  scheme  makes  it  harder  to  produce  effective  results  from  the  schedule-based  side- 
channel  attack. 

•  Randomization  with  idle  Time  Scheduling  and  Fine-grained  Switching:  To  push  the  randomization  to  an  ex¬ 
treme,  one  could  choose  to  randomize  the  schedule  every  tick.  That  is,  the  scheduler  will  randomly  pick 
a  task  to  execute,  subject  to  the  deadline  constraints,  in  every  tick  interrupt.  This  way,  we  gain  the  most 
randomness  for  the  schedule.  However,  it  greatly  increases  the  overheads  and  thus  may  not  be  applicable 
for  all  use  cases. 
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22  Attacks  and  Analysis 

One  facet  of  our  research  is  to  study  the  mechanisms  that  an  attacker  can  use  to  enter  the  system  and 
the  information  that  can  be  gained  as  a  result.  In  this  section  we  enumerate  our  ongoing  work  on  attack 
mechanisms  for  real-time  systems. 

While  examining  various  side  channel  attacks  and  the  information  each  attack  can  reveal  in  real-time 
systems,  we  identified  that  an  adversary  can  potentially  reconstruct  the  schedule  of  a  hard  real-time  sys¬ 
tem  by  observing  the  active  states  of  the  scheduler.  A  leakage  of  scheduling  behavior  of  the  system  gives 
attackers  sufficient  information  to  pinpoint  the  start  point  of  any  selected  task  and  launch  an  attack  with 
an  increased  precision  (e.g.,  cache  timing  attack)  with  minimum  footprint.  Since  this  study  focuses  on  the 
leakage  inside  of  the  system,  we  assume  that  the  attacker  has  already  gained  control  of  one  or  more  user 
tasks  as  well  as  some  amount  of  task  information  such  as  task  periods  and  execution  times.  Adversaries  in 
this  scenario  can  gain  access  to  the  system  due  to  vulnerabilities  in  either  the  system  integrator  or  untrusted 
vendors. 

We  developed  a  sophisticated  algorithm,  ScheduLeak  [1,2],  to  reconstruct  the  scheduling  based  on  the 
gathered  active  state  data  -  it  is  being  implemented  on  both,  Zedboard  (a  ARM  Cortex-A9  development 
platform  running  FreeRTOS)  and  a  simulation  tool  that  we  specifically  built  for  verifying  and  analyzing 
experiment  results.  Furthermore,  the  cache  timing  attack  that  follows  the  reconstruction  of  the  scheduling 
is  also  implemented  on  the  Zedboard. 
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Fig.  1:  Experiment  Result  of  The  Scheduling  Reconstruction,  (a)  Ground  truth  of  the  scheduling,  (b)  Busy 
intervals  captured  by  idle  task,  (c)  The  result  of  scheduling  reconstruction. 

2.2.1  Schedule  Reconstruction 

To  capture  the  state  of  the  system  schedule,  we  propose  to  use  an  observer  task ,  The  observer  task  can  be  either 
the  lowest  priority  task  owned  by  the  attacker  or  the  idle  task  that  is  injected  an  "observing  function".  Being 
the  lowest  priority  task  in  a  preemptive  real-time  system  makes  it  possible  to  measure  the  active  time  of  the 
entire  system. 

However,  measuring  the  active  time  doesn't  provide  us  with  enough  direct  information  about  the  sched¬ 
ule.  In  fact,  active  time  intervals  are  more  like  pieces  of  separate  chunks  of  busy  intervals  that  are  composed 
of  unknown  number  of  jobs  from  each  task.  Thus,  in  order  to  reconstruct  the  schedule,  we  develop  an  al- 
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gorithm  to  analyze  each  busy  interval  as  follows: 

1.  Analyze  each  busy  interval  individually  and  infer  possible  task  combinations, 

2.  Calculate  the  arrival  time  window  of  each  task  based  on  the  inferred  task  combinations  in  each  busy 

interval, 

3.  Reconstruct  the  scheduling  for  each  busy  interval  with  the  calculated  arrival  time  window. 

Step  1  focuses  on  the  problem  of  finding  the  quantity  of  each  task  constituting  a  busy  interval.  Note  that 
every  busy  interval  is  analyzed  independently  in  this  step  and  some  busy  intervals  may  result  in  multiple 
inferences.  Step  2  infers  the  possible  arrival  time  window  of  each  task  in  each  busy  interval.  For  one  task, 
the  advanced  arrival  time  window  is  calculated  by  intersecting  all  the  possible  windows  of  the  task  in  every 
busy  interval.  The  arrival  time  windows  are  then  used  by  a  compact  RM  scheduling  simulator  specific  for 
reconstructing  the  scheduling  of  any  selected  busy  interval  in  step  3. 

Figure  1  presents  the  result  of  the  reconstruction  on  the  Zedboard.  Part  (a)  shows  the  ground  truth  (the 
actual  schedule)  that  we  want  to  reveal  from  the  system.  Part  ( b)  depicts  the  busy  intervals  captured  by 
the  hijacked  idle  task.  These  busy  intervals  are  processed  by  an  analysis  algorithm,  result  from  which  are 
presented  in  part  (c) .  With  the  comparison  between  ground  truth  and  the  result  of  reconstruction,  it  shows 
that  the  proposed  attack  scheme  can  successfully  restore  the  scheduling  by  merely  observing  the  active 
state  of  the  system. 

In  the  second  year,  the  algorithm  works  under  the  assumption  that  the  task  execution  times  are  fixed  to 
the  worst  case  execution  times.  This  limits  the  developed  attack  scheme  to  the  systems  without  uncertainty. 
In  the  third  year,  we  further  relax  this  assumption  and  refine  the  algorithm  to  make  it  tolerate  variations  in 
task  execution  times.  This  makes  the  attack  applicable  to  more  realistic  use  cases. 

The  results  gained  from  this  process  will  be  used  to  launch  a  cache  timing  attack  on  a  specific  task  as 
explained  in  the  following  section. 

Note:  The  above  work  on  schedule  reconstruction  was  carried  out  in  collaboration  with  Prof.  Negar 
Kiyavash's  group  at  UIUC. 

2.2.2  Cache  Ti  mi  ng  Attack 

A  cache  timing  attack  is  a  side-channel  attack  that 
manipulates  an  indirect  (storage)  leakage  channel 
to  steal  certain  information  from  a  system.  The  at¬ 
tack  exploits  the  leakage  channel  through  the  cache 
memory  that  makes  it  possible  to  infer  the  cache 
memory  usage  of  a  specific  task. 

In  our  attack  scheme,  we  consider  compromis¬ 
ing  the  highest  priority  task.  In  contrast  to  the  idle 
task  or  the  lowest  priority  task,  a  task  with  the  high¬ 
est  priority  has  the  shortest  period  (rate-monotonic 
scheduling)  that  gives  it  privileges  to  be  scheduled 
with  a  higher  frequency  and  finish  a  complete  job 
without  being  interrupted.  These  characteristics 
are  beneficial  for  the  attacks  that  require  computa¬ 
tion  of  algorithm  in  a  continuous  time,  e.g.,  cache 
timing  attack. 

In  our  implementation,  the  attack  is  triggered 
once  we  detect  the  execution  of  a  "target"  task  - 
based  on  the  scheduling  analysis  from  Section  2.2.1. 

The  compromised  task  (with  highest  priority)  launches  the  cache  timing  attack  right  at  the  end  of  the  exe¬ 
cution  of  the  busy  interval  that  includes  the  target  task.  It  measures  the  cache  memory  usage  for  the  target 
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task.  By  replicating  this  process  multiple  times,  we  can  reasonably  infer  the  memory  usage  behavior  of  the 
target  task. 

Figure  2  shows  the  experimental  results  of  the  attack  targeting  a  task  that  switches  between  two  memory 
consumption /operational  modes:  (i)  processing  32KB  images  and  (it)  processing  100KB  images.  From  these 
results,  the  cache  usage  behavior  of  the  target  task  can  be  successfully  inferred  and  the  two  operation  modes 
are  distinguishable. 

23  Demonstration  Platform 

In  general,  a  big  challenge  for  real-time  system  researchers,  in  spite  of  innovating  new  techniques  for  com¬ 
mon  system  issues  and  supportive  mathematical  proofs,  is  to  seek  a  realistic  hardware  platform  to  demon¬ 
strate  and  implement  their  solutions  in  practice.  To  address  this  challenge,  we  have  decided  to  leverage 
the  Hexacopter  Avionics  Case  Study  developed  by  the  Real-Time  Embedded  Systems  Lab  (RESL)  at  the 
University  of  Waterloo  (U  W).  In  particular,  we  use  this  case  study  to: 

•  derive  implementation  parameter  (e.g„  flush  time,  partitioning  overhead)  required  to  drive  our  theoreti¬ 
cal  research; 

•  tes  t  the  i  m  p  l e men tabi  1  ity  o  f  devi sed  se  cu  r  i  ty  m  echa  n  i  sm s; 

•  evaluate  mechanisms  on  a  realistic  case  study  of  an  unmanned  vehicle. 

The  existing  Hexacopter  case  study  only  consisted  of  software  running  on  two  Beaglebone  boards:  one 
running  a  hardware-in-the-loop  (HIL)  module  (as  a  simulated  model  of  the  real  Plant),  and  another  board 
(Electronic  Control  Unit,  ECU)  running  an  Autopilot  application.  The  HIL  module  is  connected  to  a  real 
hexacopter  with  3-degrees  of  freedom  to  retrieve  roll,  pitch  and  yaw  information;  the  HIL  itself  simulates 
the  position  of  the  vehicle.  In  this  way,  the  platform  can  be  realistically  tested  without  the  need  to  fly  the 
UAV  outside3. 

Our  demonstrator  builds  on  top  of  the  existing  Hexacopter  ECU.  In  abstract,  sensor  data  (both  real  and 
simulated)  are  fed  from  the  HIL  to  the  ECU  over  a  bidirectional  serial  communication  port  Part  of  the 
sensor  data,  such  as  GPS,  which  are  forced  to  be  simulated  (due  to  indoor  constraints),  are  generated  by  the 
simulated  model  of  the  plant;  the  rest  are  produced  by  the  1  lexacopter  inertial  navigation  sensors.  After 
making  done  some  computations  cm  the  received  sensors  data,  the  actuation  data  is  sent  back  into  the 
simulated  plant,  again  through  the  same  serial  communication  port.  The  main  tasks  in  charge  of  the  above 
functionalities  communicates  through  global  data  structures  which  are  synchronized  by  control  variables. 
The  controller /actuator  task  that  computes  the  control  action  and  sends  actuation  data  to  the  HIL  is  periodic 
with  a  frequency  of  50Hz. 

To  properly  demonstrate  and  test  our  devised  security  mechanisms  on  the  Hexacopter  platform,  we 
mainly  worked  in  two  directions.  First,  we  implemented  a  suitable  hard  ware/ software  platform  and  ported 
the  Autopilot  application  to  the  new  platform;  second,  we  created  a  more  complex  case  study  by  including 
additional  sensing  and  communication  tasks  in  the  ECU. 

2.3.1  Platform  Implementation 

To  allow  quick  prototyping  and  testing  of  the  devised  mechanisms,  we  decided  to  migrate  the  HW/SW 
platform  to  a  multicore  FPGA-based  ARM  platform  running  the  FreeRTOS  operating  system.  The  config¬ 
urability  of  the  FPGA-based  platform  allows  us  to  easily  test  hardware-based  mechanisms.  At  the  same 
time,  the  FreeRTOS  kernel  is  lightweight  and  simple,  making  a  perfect  candidate  to  quickly  implement  and 
test  various  security-aware  scheduling  mechanisms. 

Asa  first  step,  we  performed  the  actual  HW  port,  ensuring  that  the  HIL  could  be  connected  to  the  new 
ECU  hardware,  a  Xilinx  Zynq  FPGA  board  that  can  implement  either  a  dual  core  ARM  A9  processor  or  a 

3 Note  that  UAV  regulation  is  stricter  in  Canada  compared  to  the  US:  Canada's  federal  transport  administration  inquires  written 
permission  for  every  experiment  performed  in  the  airspace. 
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2-8  soft  core  systems  (Xilinx  Microblaze).  We  also  configured  FreeRTOS  to  run  on  the  Zynq  platform*  Then, 
we  worked  on  porting  the  software  application  and  implementing  our  devised  security  mechanisms: 

1*  Autopilot  port:  we  ported  the  autopilot  application  to  FreeRTOS  running  on  a  single  core  ARM  system. 
The  previous  autopilot  version  was  running  on  Linux,  which  is  unsuitable  to  conduct  experiments  on 
hard  real-time  scheduling.  Due  to  differences  in  library  support  and  execution  semantics,  the  code  had 
to  be  significantly  updated. 

2.  Platform  characterization  and  evaluation:  we  characterized  both  the  hardware  platform  and  the  appli¬ 
cation  by  extracting  relevant  metrics,  including  scheduling  overhead,  flush  time,  worst-case  execution 
times  based  on  resource  partitioning,  etc.,  to  better  characterize  our  scheduling  analysis, 

3.  Flush  mechanism  implementation:  we  extended  FreeRTOS  to  implement  the  flushing  mechanism  for 
both  level  1  and  level  2  cache.  Our  implementation  leverages  hardware  support  to  efficiently  perform 
the  cache  flush,  and  is  able  to  check  whether  a  flush  is  required  in  constant  time  in  the  number  of  tasks* 

4.  Partitioning  implementation:  we  implemented  a  partitioning  for  level  2  cache*  Our  system  supports 
cache-way  partitioning,  where  each  task  can  be  assigned  to  one  or  more  of  the  8  available  ways  in  level 
2  cache. 

5.  Scheduling  implementation:  we  implemented  the  devised  scheduling  algorithm  in  FreeRTOS.  In  par¬ 
ticular,  the  OS  has  been  extended  to  selectively  allow  tasks  to  execute  either  preemptively  or  non- 
preemptively*  Also,  the  scheduler  has  been  modified  to  check  at  run-time  whether  a  FT  execution  is 
required  before  switching  to  a  new  task. 

Note:  While  most  of  the  above  was  implemented  at  the  University  of  Waterloo,  we  are  currently  devel¬ 
oping  some  aspects  of  the  platform  at  the  University  of  Illinois*  So  far,  we  have  been  able  to  port  FreeRTOS 
on  to  an  dual  core  ARM  zedboard  system  and  also  set  up  the  various  drivers  and  software  tasks.  Our  initial 
objective  is  to  demonstrate  a  leakage-based  attack  (Section  2,2)  on  a  realistic  platform  and  the  show  the 
efficacy  of  our  proposed  solutions* 

2,3*2  Avionics  Case  Study  and  Security  Model 

The  original  Hexacopter  case  study  comprised  only  the  Autopilot  application.  To  build  a  more  involved 
demonstrator,  we  added  other  applications  to  the  platform  to  perform  additional  sensing  and  communica¬ 
tion  tasks. 

Figure  3  shows  the  main  tasks  comprising  our  new  case  study,  as  well  as  their  communication  patterns* 
The  sensor,  control  law  and  actuator  tasks  comprise  the  existing  Autopilot  application.  We  assume  that 
the  UAV  is  employed  to  capture  reconnaissance  video  through  an  integrated  camera.  Images  are  captured 
from  the  camera  by  the  corresponding  driver,  encoded  in  a  compressed  format,  and  then  encrypted  before 
being  transmitted  to  the  base  station.  We  further  assume  that  the  Autopilot  and  Camera  subsystems  have 
been  coded  by  different  sub  vendors.  Finally,  the  system  integrator  connects  the  two  subsystems  by  means 
of  a  mission  planner  tasks,  which  determines  navigational  way-points,  and  a  network  subsystem  that  ex¬ 
changes  information  with  a  base  station  through  wireless  communication*  Some  tasks  must  be  protected 
{e.g.,  because  of  their  security  classifications,  or  because  they  contain  proprietary  algorithms)  and  should 
not  leak  information  to  tasks  of  other  vendors*  This  vendor-oriented  security  model  creates  a  non-trivial  se¬ 
curity  relation  between  the  various  tasks,  which  makes  enforcing  security  requirements  challenging.  Note: 
This  above  model  was  developed  in  collaboration  with  Stanley  Bak,  a  researcher  from  Air  Force  Research 
Labs,  Rome,  NY* 

In  particular,  we  were  able  to  demonstrate  that  the  discussed  vendor-oriented  security  constraints  cannot 
be  modelled  by  a  standard  multi-level  security  model*  This  is  because  standard  models  consider  a  lattice 
(i,e*,  a  partial  order)  of  security  levels,  which  implies  that  security  relations  must  be  transitive:  if  a  task 
Ti  must  be  protected  from  r2  and  r2  must  be  protected  from  t;j,  then  7]  should  be  protected  from  r3  as 
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Fig.  3:  Avionics  Case  Study:  Tasks  and  Protection  Assignments 


well.  However,  this  is  not  the  case  in  our  discussed  case  study:  for  example,  the  Encryption  task  must  be 
protected  from  Control  Laws,  and  Control  Laws  must  be  protected  from  Camera  Driver,  but  Encryption 
does  not  need  to  be  protected  from  Camera  Driver,  since  they  belong  to  the  same  sub  vendor.  Hence,  to 
properly  capture  the  requirements  in  our  case  study,  we  developed  a  new  generic  model  consisting  of  a 
matrix  of  security  requirements  (nodeakage)  between  any  two  tasks*  The  model  has  then  been  used  as 
the  basis  of  our  theoretical  analysis  discussed  in  Section  2.1.  Furthermore,  the  FreeRTOS  implementation 
described  in  Section  2.3.1  directly  implements  the  discussed  model  by  incorporating  the  no-leakage  relation 
in  the  descriptor  of  each  real-time  task. 

In  Year  I,  we  ported  the  hexacopter  demonstrator  to  the  described  platform,  implemented  the  avionics 
case  study,  and  realized  the  flush  mechanism.  In  Year  II,  we  devised  the  vendor-oriented  model,  imple¬ 
mented  the  partitioning  scheme,  performed  platform  characterization  and  testing,  and  implemented  the 
devised  schemes  in  the  FreeRTOS  scheduler* 
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